Systems And Methods For Preventing Code Injection In Virtualized Environments

ABSTRACT

Described systems and methods allow protecting a host system from malicious injection of code and/or data. A memory introspection engine operates below an operating system (OS), having higher processor privileges than the OS. The memory introspection engine is configured to selectively block the copying of memory between a source process and a destination process, thus preventing the injection of code and/or data, particularly from or into user-mode processes. To prevent inter-process memory copying, some embodiments hook a native OS function carrying out such copy operations. A subsequent call to the hooked function may either carry out or block the requested copy operation, according to a set of decision criteria based on the identity of the source process and/or the identity of the destination process.

BACKGROUND

The invention relates to systems and methods for protecting computersystems from malware.

Malicious software, also known as malware, affects a great number ofcomputer systems worldwide. In its many forms such as computer viruses,worms, rootkits, and spyware, malware presents a serious risk tomillions of computer users, making them vulnerable to loss of data andsensitive information, identity theft, and loss of productivity, amongothers.

A typical way to carry out malicious activities in a host systeminvolves injecting code and/or data into a process already executing onthe respective system. By executing within the memory space of thetargeted process, such malicious code may have direct access to theresources of the targeted process, and may conduct various activitiesmasquerading as the respective process. In one such example, to stealsensitive data such as credit card details of a user accessing ane-commerce website, a malware agent may inject a piece of code into theweb browser, the respective piece of code configured to record datainput by the user. In another example, malware trying to hide a file ona hard drive of the host system may inject a piece of code into a filemanagement process, such as Windows Explorer®.

Another common type of malware is used to circumvent copyrightprotection of digital data. Such malware may be configured to copy data,such as user keys or protected content, from a targeted process.

Hardware virtualization technology allows the creation of simulatedcomputer environments commonly known as virtual machines, which behavein many ways as physical computer systems. In typical modernapplications, such as server consolidation andinfrastructure-as-a-service (IAAS), several virtual machines may runsimultaneously on the same physical machine, sharing the hardwareresources among them, thus reducing investment and operating costs. Eachvirtual machine may run its own operating system and/or softwareapplications, separately from other virtual machines.

Due to the steady proliferation of malware, each such virtual machinepotentially requires malware protection, including protection againstmalicious code injection and data theft. There is considerable interestin developing efficient, robust, and scalable anti-malware solutions forhardware virtualization platforms.

SUMMARY

According to one aspect, a host system comprises a hardware processorconfigured to operate a virtual machine and a memory introspectionengine executing outside the virtual machine. The virtual machinecomprises a virtualized processor and is configured to employ thevirtualized processor to execute a source process and a destinationprocess. The memory introspection engine is configured to intercept anattempt to copy a content of memory from a virtual memory space of thesource process to a virtual memory space of the destination process, andto identify the source and destination processes according to theattempt. The memory introspection engine is further configured to, inresponse to identifying the source and destination process, selectivelyblock the attempt according to a selection criterion determinedaccording to at least one member of a group consisting of an identity ofthe source process and an identity of the destination process.

According to another aspect, a method comprises employing at least onehardware processor of a host system to execute a memory introspectionengine, the memory introspection engine executing outside of a virtualmachine exposed by the host system. The virtual machine comprises avirtualized processor and is configured to employ the virtualizedprocessor to execute a source process and a destination process.Executing the memory introspection engine comprises intercepting anattempt to copy a content of memory from a virtual memory space of thesource process to a virtual memory space of the destination process, andidentifying the source and destination processes according to theattempt. Executing the memory introspection engine further comprises, inresponse to identifying the source and destination processes,selectively blocking the attempt according to a selection criteriondetermined according to at least one member of a group consisting of anidentity of the source process and an identity of the destinationprocess.

According to another aspect, a non-transitory computer-readable mediumstores instructions which, when executed by at least one hardwareprocessor of a host system, cause the host system to form a memoryintrospection engine executing outside a virtual machine exposed by thehost system. The virtual machine comprises a virtualized processor, andis configured to employ the virtualized processor to execute a sourceprocess and a destination process. The memory introspection engine isconfigured to intercept an attempt to copy a content of memory from avirtual memory space of the source process to a virtual memory space ofthe destination process, and to identify the source and destinationprocesses according to the attempt. The memory introspection engine isfurther configured to, in response to identifying the source anddestination processes, selectively block the attempt according to aselection criterion determined according to at least one member of agroup consisting of an identity of the source process and an identity ofthe destination process.

BRIEF DESCRIPTION OF THE DRAWINGS

The foregoing aspects and advantages of the present invention willbecome better understood upon reading the following detailed descriptionand upon reference to the drawings where:

FIG. 1 shows an exemplary set of virtual machines exposed by ahypervisor executing on a host system, and a memory introspection engineprotecting the set of virtual machines according to some embodiments ofthe present invention.

FIG. 2 shows an exemplary hardware configuration of the host systemaccording to some embodiments of the present invention.

FIG. 3 shows an exemplary configuration of virtualized hardware exposedto a guest virtual machine according to some embodiments of the presentinvention.

FIG. 4 illustrates an exemplary hierarchy of software objects executingon the host system at various processor privilege levels, including aset of objects protected from malware according to some embodiments ofthe present invention.

FIG. 5 shows an exemplary mapping of memory addresses in someembodiments of the present invention.

FIG. 6 shows a typical sequence of steps carried out by malware toinject code and/or data into a destination process.

FIG. 7 shows an exemplary sequence of steps performed by the memoryintrospection engine to protect a guest virtual machine according tosome embodiments of the present invention.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

In the following description, it is understood that all recitedconnections between structures can be direct operative connections orindirect operative connections through intermediary structures. A set ofelements includes one or more elements. Any recitation of an element isunderstood to refer to at least one element. A plurality of elementsincludes at least two elements. Unless otherwise required, any describedmethod steps need not be necessarily performed in a particularillustrated order. A first element (e.g. data) derived from a secondelement encompasses a first element equal to the second element, as wellas a first element generated by processing the second element andoptionally other data. Making a determination or decision according to aparameter encompasses making the determination or decision according tothe parameter and optionally according to other data. Unless otherwisespecified, an indicator of some quantity/data may be the quantity/dataitself, or an indicator different from the quantity/data itself. Unlessotherwise specified, a process is an instance of a computer program,such as an application or a part of an operating system, and ischaracterized by having at least an execution thread and a virtualmemory space assigned to it by the operating system, wherein a contentof the respective virtual memory space includes executable code. Unlessotherwise specified, a page represents the smallest unit of virtualmemory that can be individually mapped to a physical memory of a hostsystem. Computer readable media encompass non-transitory media such asmagnetic, optic, and semiconductor storage media (e.g. hard drives,optical disks, flash memory, DRAM), as well as communication links suchas conductive cables and fiber optic links. According to someembodiments, the present invention provides, inter alia, computersystems comprising hardware (e.g. one or more processors) programmed toperform the methods described herein, as well as computer-readable mediaencoding instructions to perform the methods described herein.

The following description illustrates embodiments of the invention byway of example and not necessarily by way of limitation.

FIG. 1 shows an exemplary configuration of a host system 10 running ahardware virtualization platform and protected from malware according tosome embodiments of the present invention. Host system 10 may representa corporate computing device such as an enterprise server, or anend-user device such as a personal computer, tablet computer, orsmartphone. Other exemplary host systems include entertainment devicessuch as TVs and game consoles, or any other device having a memory and aprocessor, and requiring malware protection. In the example of FIG. 1,host system 10 executes a set of guest virtual machines 32 a-b, exposedby a hypervisor 30. A virtual machine (VM) comprises an abstraction,e.g., a software emulation, of an actual physical machine/computersystem, the VM capable of running an operating system and otherapplications. Hypervisor 30 includes software configured to create aplurality of virtualized devices, such as a virtual processor and avirtual memory controller, and to present such virtualized devices tosoftware in place of the real, physical devices of host system 10. Suchoperations of hypervisor 30 are commonly known in the art as exposing avirtual machine. In some embodiments, hypervisor 30 allows amultiplexing (sharing) by multiple virtual machines of hardwareresources of host system 10. Hypervisor 30 may further manage suchmultiplexing so that each VM operates independently and is unaware ofother VMs executing concurrently executing on host system 10. Examplesof popular hypervisors include the VMware vSphere™ from VMware Inc. andthe open-source Xen hypervisor, among others.

Each VM 32 a-b may execute a guest operating system (OS) 34 a-b,respectively. A set of exemplary applications 42 a-d genericallyrepresent any software application, such as word processing, imageprocessing, media player, database, calendar, personal contactmanagement, browser, gaming, voice communication, data communication,and anti-malware applications, among others. Operating systems 34 a-bmay comprise any widely available operating system such as MicrosoftWindows®, MacOS®, Linux®, iOS®, or Android™, among others. Each OSprovides an interface between applications executing within a virtualmachine and the virtualized hardware devices of the respective VM. Inthe following description, software executing on a virtual processor ofa virtual machine is said to execute within the respective virtualmachine. For instance, in the example of FIG. 1, applications 42 a-b aresaid to execute within guest VM 32 a, while applications 42 c-d are saidto execute within guest VM 32 b. In contrast, hypervisor 30 is said toexecute outside, or below, guest VMs 32 a-b.

In some embodiments, hypervisor 30 includes a memory introspectionengine 40, configured to perform anti-malware operations as describedfurther below. Engine 40 may be incorporated into hypervisor 30, or maybe delivered as a software component distinct and independent fromhypervisor 30, but executing at substantially similar processorprivilege level as hypervisor 30. A single engine 40 may be configuredto malware-protect multiple VMs executing on host system 10.

FIG. 2 shows an exemplary hardware configuration of host system 10.System 10 comprises a set of physical devices, including a processor 12,a memory unit 14, a set of input devices 16, a set of output devices 18,a set of storage devices 20, and a set of network adapters 22, allconnected by a controller hub 24. In some embodiments, processor 12comprises a physical device (e.g. multi-core integrated circuit formedon a semiconductor substrate) configured to execute computational and/orlogical operations with a set of signals and/or data. In someembodiments, such logical operations are delivered to processor 12 inthe form of a sequence of processor instructions (e.g. machine code orother type of software). Memory unit 14 may comprise volatilecomputer-readable media (e.g. RAM) storing data/signals accessed orgenerated by processor 12 in the course of carrying out instructions.

Input devices 16 may include computer keyboards, mice, and microphones,among others, including the respective hardware interfaces and/oradapters allowing a user to introduce data and/or instructions into hostsystem 10. Output devices 18 may include display devices such asmonitors and speakers, among others, as well as hardwareinterfaces/adapters such as graphic cards, allowing host system 10 tocommunicate data to a user. In some embodiments, input devices 16 andoutput devices 18 may share a common piece of hardware, as in the caseof touch-screen devices. Storage devices 20 include computer-readablemedia enabling the non-volatile storage, reading, and writing ofprocessor instructions and/or data. Exemplary storage devices 20 includemagnetic and optical disks and flash memory devices, as well asremovable media such as CD and/or DVD disks and drives. The set ofnetwork adapters 22 enables host system 10 to connect to a computernetwork and/or to other devices/computer systems. Controller hub 24generically represents the plurality of system, peripheral, and/orchipset buses, and/or all other circuitry enabling the communicationbetween processor 12 and devices 14, 16, 18, 20 and 22. For instance,controller hub 24 may include a memory controller, an input/output (I/O)controller, and an interrupt controller, among others. In anotherexample, controller hub 24 may comprise a northbridge connectingprocessor 12 to memory 14 and/or a southbridge connecting processor 12to devices 16, 18, 20, and 22.

FIG. 3 shows an exemplary configuration of a virtual machine 32, asexposed by hypervisor 30. VM 32 may represent any of VMs 32 a-b ofFIG. 1. VM 32 includes a virtualized processor 112, a virtualized memoryunit 114, virtualized input devices 116, virtualized output devices 118,virtualized storage 120, virtualized network adapters 122, and avirtualized controller hub 124. Virtualized processor 112 comprises anemulation of at least some of the functionality of processor 12, and isconfigured to receive for execution processor instructions forming partof software such as an operating system and other applications. Softwareusing processor 112 for execution is deemed to execute within virtualmachine 32. In some embodiments, virtualized memory unit 114 comprisesaddressable spaces for storing and retrieving data used by virtualizedprocessor 112. Other virtualized devices (e.g., virtualized input,output, storage, etc.) emulate at least some of the functionality of therespective physical devices of host system 10. Virtualized processor 112may be configured to interact with such devices as it would with thecorresponding physical devices. For instance, software executing withinVM 32 may send and/or receive network traffic via virtualized networkadapter(s) 122. In some embodiments, hypervisor 30 may expose only asubset of virtualized devices to VM 32 (for instance, only virtualizedprocessor 112, virtualized memory 114, and parts of hub 124). Hypervisor30 may also give a selected VM exclusive use of some hardware devices ofhost system 10. In one such example, VM 32 a (FIG. 1) may have exclusiveuse of input devices 16 and output devices 18, but lack a virtualizednetwork adapter. Meanwhile, VM 32 b may have exclusive use of networkadapter(s) 22. Such configurations may be implemented, for instance,using VT-d® technology from Intel.

FIG. 4 illustrates an exemplary hierarchy of software objects executingon host system 10 according to some embodiments of the presentinvention. FIG. 4 is represented from the perspective of processorprivilege levels, also known in the art as layers or protection rings.In some embodiments, hypervisor 30 takes control of processor 12 at themost privileged level (e.g., VMXroot on Intel platforms supportingvirtualization, also known as ring-1, or root mode), thus creating ahardware virtualization platform exposed as virtual machine 32 to othersoftware executing on host system 10. An operating system 34, such asguest OSs 34 a-b in FIG. 1, executes within the virtual environment ofVM 32, OS 34 having lesser processor privilege than hypervisor 30 (e.g.,ring 0 or kernel mode). A set of applications 42 e-f execute at lesserprocessor privilege than OS 34 (e.g., ring 3 or user mode). Parts ofapplications 42 e-f may execute at kernel privilege level, for instancea driver 36 installed by application 42 e. Some parts of OS 34 mayexecute in user mode (ring 3).

An exemplary driver 36 may perform anti-malware operations, and in someembodiments even collaborate with introspection engine 40. Such ananti-malware component executing within guest VM 32 may have someadvantages. For instance, determining various information about runningprocesses and threads may be substantially easier to do from withinguest VM 32, than from the level of engine 40. In one example, driver 36may identify processes currently running within VM 32. In anotherexample, driver 36 may determine a memory address of a resource used bya process, and communicate the address to engine 40. In yet anotherexample, driver 36 may receive a message from engine 40 and in response,display a malware warning message to a user of guest VM 32.Communication between components executing inside guest VM 32 and engine40 may be carried out using any method known in the art ofvirtualization (for instance, via a dedicated section of memoryaccessible to both engine 40 and driver 36).

In some embodiments, introspection engine 40 executes substantially atthe same processor privilege level as hypervisor 30 (e.g., ring-1 orroot mode), and is configured to perform introspection of virtualmachines executing on host system 10, such as VM 32. Introspection of aVM, or of a software object executing within the respective VM, maycomprise analyzing a behavior of the respective software object. Forinstance, introspection may comprise detecting an action performed bythe object (e.g., calling certain functions of the OS, accessing aregistry of the OS, downloading a file from a remote location, writingdata to a file, etc.). Introspection may further comprise determiningaddresses of memory sections containing parts of the software object,accessing the respective memory sections, and analyzing a content storedwithin the respective memory sections. Other examples of introspectioninclude intercepting and/or restricting access to such memory sections,e.g., preventing the over-writing of code or data belonging to aprotected process, and preventing the execution of code stored incertain memory pages. Yet another example of introspection comprisesselectively denying the copying of code and/or data between distinctprocesses executing on the respective VM, as shown in detail below.

In some embodiments, memory introspection engine 40 sets up a protectedarea 38 comprising a set of processes selected for malware protectionfrom a list of processes currently executing within guest VM 32.Protecting a process may comprise denying the copying of code and/ordata to and/or from a virtual memory space of the respective process. Inthe example of FIG. 4, protected area 38 includes a protected OS process37 and all processes of application 42 e. In some embodiments, protectedarea 38 includes all processes executing at the user level of processorprivilege (user mode, or ring 3). Each protected process may beidentified, for instance, according to a unique identifier (e.g.,process ID) assigned to the respective process by guest OS 34.

To select processes for protection, memory introspection engine 40 mayaccess a list of processes currently executing within guest VM 32, thelist maintained by guest OS 34, and select processes according toprocess type (e.g., browser, file manager, etc.), and/or according toother criteria. For instance, engine 40 may select a process forprotection according to whether the respective process is user-defined,as opposed to being a part of guest OS 34 or of a predetermined set oftrusted applications. In some embodiments, engine 40 may rely on acomponent from within VM 32 (e.g., on driver 36) to identify currentlyrunning processes. In another exemplary embodiment, memory introspectionengine may hook an OS function responsible for inserting a process intothe list of currently executing processes. An example of such a functionis PspinsertProcess in Windows®. Similar functions exist in otheroperating systems, such as Linux®. Every time a process is launched, therespective hook may transfer execution to a handler routine of engine40, thus notifying engine 40 of the launch. Engine 40 may thendetermine, for instance according to predetermined selection criteria,whether the currently launched process needs protection.

To be able to perform introspection of VM 32 in a configuration asillustrated in FIG. 1 (i.e., from outside the respective VM), someembodiments of engine 40 employ memory mapping structures and mechanismsof processor 12. Virtual machines typically operate with a virtualizedphysical memory (see, e.g., memory 114 in FIG. 3), also known in the artas guest-physical memory. Virtualized physical memory comprises anabstract representation of the actual physical memory 14, for instanceas a contiguous space of addresses specific to each guest VM, with partsof said space mapped to addresses within physical memory 14 and/orphysical storage devices 20. In systems configured to supportvirtualization, such mapping is typically achieved via dedicated datastructures and mechanisms controlled by processor 12, known as secondlevel address translation (SLAT). Popular SLAT implementations includeextended page tables (EPT, on Intel® platforms), and nested page tables(NPT, on AMD® platforms). In such systems, virtualized physical memorymay be partitioned in units known in the art as pages, a pagerepresenting the smallest unit of virtualized physical memoryindividually mapped to physical memory via mechanisms such as EPT and/orNPT, i.e., mapping between physical and virtualized physical memory isperformed with page granularity. All pages typically have apredetermined size, e.g., 4 kilobytes, 2 megabytes, etc. Thepartitioning of virtualized physical memory into pages is usuallyconfigured by hypervisor 30. In some embodiments, hypervisor 30 alsoconfigures the EPT/NPT and therefore the mapping between physical memoryand virtualized physical memory. The actual mapping (translation) of avirtualized physical memory address to a physical memory address maycomprise looking up the physical memory address in a translationlookaside buffer (TLB) of host system 10. In some embodiments, addresstranslation comprises performing a page walk, which includes a set ofsuccessive address look-ups in a set of page tables and/or pagedirectories, and performing calculations such as adding an offset of apage to an address relative to the respective page.

In some embodiments, OS 34 configures a virtual memory space for aprocess such as applications 42 e-f in FIG. 4, by maintaining a mapping(address translation) between the respective virtual memory space andthe virtualized physical memory of VM 32, for instance using a pagetable mechanism. In some embodiments, the process virtual memory spaceis also partitioned into pages, such pages representing the smallestunit of virtual memory individually mapped to virtualized physicalmemory by OS 34, i.e., virtual to virtualized-physical memory mapping isperformed with page granularity.

FIG. 5 illustrates an exemplary mapping (translation) of memoryaddresses in an embodiment as shown in FIG. 1. Following exposure byhypervisor 30, each guest VM 32 a-b sees a virtualized physical memoryspace 114 a-b, respectively, as its own physical memory space. Asoftware object (e.g., a protected process) executing within guest VM 32a is assigned a virtual memory space 214 a by guest OS 34 a. When thesoftware object attempts to access a content of an exemplary memory page60 a of space 214 a, an address of page 60 a is translated by thevirtualized processor of guest VM 32 into an address of a page 60 b ofvirtualized physical memory space 114 a of VM 32, according to pagetables configured and controlled by guest OS 34 a. The address of page60 b is further mapped by physical processor 12 to an address of a page60 c within physical memory 14 of host system 10, for instance usingSLAT means configured by hypervisor 30.

Meanwhile, guest OS 34 b sets up a virtual memory space 214 b for asoftware object executing within guest VM 32 b. A page 60 d within space214 b is mapped by the virtualized processor of VM 32 b, for instancevia page tables set up by OS 34 b, to a page 60 e of guest-physicalspace 114 b. The address of page 60 e is further translated by physicalprocessor 12 to an address of a page 60 f within physical memory, viaSLAT configured by hypervisor 30.

In some embodiments, hypervisor 30 sets up its own virtual memory space214 c comprising a representation of physical memory 14, and employs atranslation mechanism (for instance, page tables) to map addresses inspace 214 c to addresses in physical memory 14. In FIG. 5, such anexemplary mapping translates the address of a page 60 k within virtualspace 214 c to the physical address of page 60 c, and the address of apage 60 m to the physical address of page 60 f. Such mappings allowhypervisor 30 to manage (e.g., read from, write to, and control accessto) memory pages belonging to software objects executing within variousVMs running on host system 10.

FIG. 6 shows a typical sequence of steps performed by malware to injectcode and/or data into a destination process, e.g., a browser. In a step302, a (malicious) source process may obtain a handle of the destinationprocess. In Windows®, for instance, step 302 may include a call to theOpenProcess function of the OS. Next, a step 304 allocates memory withinthe virtual memory space of the destination process, the allocatedmemory reserved for holding a section of injected code and/or data. In astep 306, the respective injected code and/or data is copied from thevirtual memory space of the source process to the allocated section ofthe memory space of the destination process. A step 308 then creates aremote thread configured to execute the injected code. In someembodiments, memory introspection engine 40 protects the source and/ordestination process from malware by preventing the execution of step306, i.e., by preventing the copying of code and/or data between thesource and destination processes, as shown in more detail below.

FIG. 7 shows an exemplary sequence of steps performed by memoryintrospection engine 40 to protect guest VM 32 from malware according tosome embodiments of the present invention. Engine 40 may be configuredprotect a plurality of virtual machines executing concurrently on hostsystem 10. The steps illustrated in FIG. 7 may be repeated for each suchvirtual machine. Following the initialization of guest OS 34 (step 312),in a step 314, introspection engine 40 may identify the type of OScurrently running within guest VM 32. Exemplary OS types includeWindows, Linux, MacOS, and Android, among others. OS type may furthercomprise a version indicator, such as 7, Home, or Enterprise, amongothers. In some embodiments, step 314 comprises listening from outsideguest VM 32 for processor events indicative of OS initialization.Instructions that perform OS initialization operations typically requiresubstantial processor privileges, e.g., ring 0 on Intel platforms.Processor 12 may be configured by hypervisor 30 so that the execution ofsuch instructions triggers a virtual machine exit event (e.g., VMExit onIntel® platforms), which transfers control of processor 12 from OS 34 tohypervisor 30. By intercepting such events, introspection engine 40 maythus receive information about the initialization of guest OS 34.

In an illustrative embodiment, engine 40 may intercept an attempt byguest OS to write to a model-specific register (MSR) of guest VM 32, andidentify the type of OS according to a content of the respective MSR,according to a section of memory pointed to by the respective MSR, oraccording to a parameter of the write instruction. Exemplary MSRs whichmay allow identification of the OS include, among others, aSYSENTER/SYSCALL MSR. Engine 40 may further use pattern matching againsta pre-determined library of fast system-call handlers specific to eachOS (e.g., system calls handled according to a content of the SYSCALL orSYSENTER MSRs). Such fast system-call libraries may be provided withmemory introspection engine 40, and may be kept up to date via periodicor on-demand software updates. In some embodiments, a version indicator(such as a release name, build number, etc.) may be obtained by parsingcertain kernel data structures specific to the respective type of OS.Exemplary data structures allowing identification of OS version arecertain export symbols of the Linux kernel or certain exported symbolsof the Windows kernel, such as the NtBuildNumber, among others.

Once the type of OS is identified, in a step 316, engine 40 may identifya native OS function performing inter-process copying of code and/ordata within guest VM 32. An exemplary function carrying out suchoperations in a Windows® environment is MmCopyVirtualMemory. Identifyingthe respective function may include, for instance, determining a memoryaddress of the function, which may be achieved, for instance, by parsingcertain OS-specific data structures, such as the exported functionstables of the kernel binary images (e.g. Portable Executable in Windows,Executable and Linkable Format in Linux). Another exemplary manner ofidentifying the native OS function is by parsing its code in search fora set of identifying patterns.

In a step 318, engine 40 may proceed to modify the native OS function toprovide it with additional functionality. Such modifications may beachieved using any hooking method known in the art. For instance, engine40 may apply a re-direction patch, such as a VMCall instruction or a JMPinstruction, over-written or added to the respective native OS function.Other embodiments may modify an EPT entry of the respective OS function,to point to a new address. In some embodiments, the effect of suchhooking is to redirect execution of the native OS function responsiblefor inter-process memory copying operations to a fragment of codeprovided by engine 40; exemplary functionality of such code is givenbelow (steps 324-334). Following hooking, when OS 34 attempts to copy acontent of memory between two processes, the respective fragment of codewill be executed before or instead of the code of the native OSfunction.

Introspection engine 40 may now return control of processor 12 to guestVM 32. In a sequence of steps 320-322, guest VM 32 may execute currentprocesses and/or applications until one such process issues a call tothe OS function hooked in step 318. The call is intercepted via thehooking mechanism, suspending execution of guest VM 32 and transferringexecution to introspection engine 40.

In a step 324, engine 40 may identify a source process and a destinationprocess of the intercepted memory copy operation, for instance,according to parameters or arguments of the intercepted function call. Astep 326 may determine whether either the source or the destinationprocess requires malware protection, i.e., is part of protected area 38(FIG. 4). Step 326 may comprise, for instance, looking up the sourceand/or destination process within the list of protected processes. Whenneither the source, nor the destination process require protection, in astep 328 engine 40 returns execution to the native OS function, to carryout the respective memory copy operation.

When either the source process or the destination process requiresprotection, in a step 330, engine 40 may apply a set of criteria todetermine whether the respective memory copy operation should beallowed. In some embodiments, step 330 comprises determining whether therespective memory copy operation is malware-indicative, as opposed tolegitimate. There may be various situations in which copying memory fromone process to another is legitimate. For instance, when launching achild process, a parent process may legitimately inject code and/or datainto the child process. In another example, some system processes (i.e.,processes of guest OS 34) may legitimately inject code/data into otherprocesses.

Other exemplary criteria for determining whether to allow the memorycopy include, among others, an owner of the source and/or destinationprocess, a source address and/or a destination address of the memorysection being copied, a size, and a content of the respective section ofmemory. In one example, engine 40 may determine, according to a contentand/or to an address of the respective memory section, what kind ofresource is being copied between the source and destination processes.One such exemplary resource is a library (e.g., a dynamic-linkedlibrary, or DLL in Windows®). In another example, engine 40 maydetermine according to a destination address what part of thedestination process will receive the copied content. For instance,engine 40 may determine whether the injected code/data will be copied toa region of memory allocated for the stack or the heap of thedestination process. An attempt to write to such memory regions may bemalware-indicative.

When a step 332 determines that the memory copy should be allowed,introspection engine 40 returns execution to the native OS memory copyfunction (step 328). When no, a step 334 may block the respective memorycopy operation. For instance, step 334 may return an error (e.g.,STATUS_ACCESS_DENIED) to a caller of the memory copy function. In someembodiments, step 334 may further comprise alerting a systemadministrator and/or displaying a warning to a user of guest VM 32.

A skilled artisan will appreciate that, while FIG. 7 shows steps324-326-330-332 executing outside guest VM 32, such steps may be alsocarried out from within guest VM 32. In one such example, engine 40 mayinject a fragment of code providing the functionality of said steps intoa memory space used by VM 32, and configure the hook (step 318 above) toredirect execution to the injected code.

The exemplary systems and methods described above allow protecting acomputer system from malware using hardware virtualization technology.In some embodiments, a hypervisor operates at the highest level ofprocessor privilege (e.g., ring-1 or root mode), and displaces theoperating system to a virtual machine. An introspection engine executesat the level of the hypervisor, i.e., below all virtual machines exposedon the host system, thus performing anti-malware activities from aposition of higher privilege than the operating system. Theintrospection engine may block the illegitimate copying of code and/ordata to and/or from the memory space of a protected process executingwithin a virtual machine, thus preventing malicious code injectionand/or data theft. A single such introspection engine may protectmultiple virtual machines operating on the same hardware platform. Insome embodiments, protected processes execute at user-level of processorprivilege (e.g., ring 3 or user mode).

In some embodiments, to prevent inter-process copying of code and/ordata, the introspection engine may hook a native OS function performinginter-process memory copy operations, and redirect execution of thenative OS function to a fragment of code executing outside therespective VM, at the privilege level of the hypervisor. Alternatively,the fragment of code executes within the respective VM, and is injectedinto the memory of the respective VM from the level of the hypervisor.The fragment of code may determine whether to allow the respectivememory copy operation according to a set of criteria, such as theidentity of the source and/or destination process, the owner of thesource and/or destination process, the size, and the content of thecopied section of memory. When a decision is made to allow the copyingof memory between the source and destination process, the introspectionengine may return execution to the native OS function. When the copyingis not allowed, the introspection engine may simply block the copyoperation, for instance by returning an error to a caller of the nativeOS function.

Conventional anti-malware solutions are typically tailored to a singleoperating system. Switching between one operating system and another mayrequire loading a different version of anti-malware software. Incontrast, in some embodiments of the present invention, the same memoryintrospection engine may malware-protect the respective computer system,irrespective of the type and version of operating system is currentlyrunning. By executing the memory introspection engine at the level of ahypervisor, and by displacing the operating system to a virtual machine,some embodiments may run and protect several operating systemsconcurrently. In some embodiments, the memory introspection engine maydynamically identify each operating system, for instance on boot-up, andmay further protect OS-specific software objects and data structures.

It will be clear to a skilled artisan that the above embodiments may bealtered in many ways without departing from the scope of the invention.Accordingly, the scope of the invention should be determined by thefollowing claims and their legal equivalents.

What is claimed is:
 1. A host system comprising a hardware processorconfigured to operate: a virtual machine comprising a virtualizedprocessor, the virtual machine configured to employ the virtualizedprocessor to execute a source process and a destination process; and amemory introspection engine executing outside the virtual machine andconfigured to: intercept an attempt to copy a content of memory from avirtual memory space of the source process to a virtual memory space ofthe destination process; identify the source and destination processesaccording to the attempt; and in response to identifying the source anddestination process, selectively block the attempt according to aselection criterion determined according to at least one member of agroup consisting of an identity of the source process and an identity ofthe destination process.
 2. The host system of claim 1, whereinintercepting the attempt comprises modifying a memory managementfunction of an operating system executing within the virtual machine,the modification causing the hardware processor to switch from executingthe memory management function to executing the memory introspectionengine in response to the attempt.
 3. The host system of claim 1,wherein intercepting the attempt comprises detecting a call to a memorymanagement function of an operating system executing within the virtualmachine, the memory management function carrying inter-process memorycopying operations.
 4. The host system of claim 1, wherein the memoryintrospection engine is configured to malware-protect a set of targetprocesses executing within the virtual machine, and wherein selectivelyblocking the attempt comprises determining whether the source processbelongs to the set of target processes.
 5. The host system of claim 1,wherein the memory introspection engine is configured to malware-protecta set of target processes executing within the virtual machine, andwherein selectively blocking the attempt comprises determining whetherthe destination process belongs to the set of target processes.
 6. Thehost system of claim 1, wherein selectively blocking the attemptcomprises: determining a destination address for the content within thememory space of the destination process; and determining whether toblock the attempt according to the destination address.
 7. The hostsystem of claim 6, wherein determining whether to block the attemptcomprises identifying a type of resource of the destination processcurrently residing at the destination address.
 8. The host system ofclaim 1, wherein the selection criterion is further determined accordingto an owner of the source process.
 9. The host system of claim 1,wherein the selection criterion is further determined according to thecontent of memory.
 10. The host system of claim 1, wherein the selectioncriterion is further determined according to whether the destinationprocess is a child of the source process.
 11. The host system of claim1, wherein selectively blocking the attempt comprises: determiningwhether the attempt is malware-indicative according to the selectioncriterion; and in response: when the attempt is not malware-indicative,allowing the execution of the attempt; and when the attempt ismalware-indicative, returning an error to an entity performing theattempt.
 12. A method comprising employing at least one hardwareprocessor of a host system to execute a memory introspection engine, thememory introspection engine executing outside of a virtual machineexposed by the host system, the virtual machine comprising a virtualizedprocessor and configured to employ the virtualized processor to executea source process and a destination process, and wherein executing thememory introspection engine comprises: intercepting an attempt to copy acontent of memory from a virtual memory space of the source process to avirtual memory space of the destination process; identifying the sourceand destination processes according to the attempt; and in response toidentifying the source and destination processes, selectively blockingthe attempt according to a selection criterion determined according toat least one member of a group consisting of an identity of the sourceprocess and an identity of the destination process.
 13. The method ofclaim 12, wherein intercepting the attempt comprises employing thememory introspection engine to modify a memory management function of anoperating system executing within the virtual machine, the modificationcausing the hardware processor to switch from executing the memorymanagement function to executing the memory introspection engine inresponse to the attempt.
 14. The method of claim 12, whereinintercepting the attempt comprises detecting a call to a memorymanagement function of an operating system executing within the virtualmachine, the memory management function carrying inter-process memorycopying operations.
 15. The method of claim 12, wherein the memoryintrospection engine is configured to malware-protect a set of targetprocesses executing within the virtual machine, and wherein selectivelyblocking the attempt comprises determining whether the source processbelongs to the set of target processes.
 16. The method of claim 12,wherein the memory introspection engine is configured to malware-protecta set of target processes executing within the virtual machine, andwherein selectively blocking the attempt comprises determining whetherthe destination process belongs to the set of target processes.
 17. Themethod of claim 12, wherein selectively blocking the attempt comprises:determining a destination address for the content within the memoryspace of the destination process; and determining whether to block theattempt according to the destination address.
 18. The method of claim17, wherein determining whether to block the attempt comprisesidentifying a type of resource of the destination process currentlyresiding at the destination address.
 19. The method of claim 12, whereinthe selection criterion is further determined according to an owner ofthe source process.
 20. The method of claim 12, wherein the selectioncriterion is further determined according the content of memory.
 21. Themethod of claim 12, wherein the selection criterion is furtherdetermined according to whether the destination process is a child ofthe source process.
 22. The method of claim 12, wherein selectivelyblocking the attempt comprises: determining whether the attempt ismalware-indicative according to the selection criterion; and inresponse: when the attempt is not malware-indicative, allowing theexecution of the attempt; and when the attempt is malware-indicative,returning an error to an entity performing the attempt.
 23. Anon-transitory computer-readable medium storing instructions which, whenexecuted by at least one hardware processor of a host system, cause thehost system to form a memory introspection engine executing outside avirtual machine exposed by the host system, wherein the virtual machinecomprises a virtualized processor, wherein the virtual machine isconfigured to employ the virtualized processor to execute a sourceprocess and a destination process, and wherein the memory introspectionengine is configured to: intercept an attempt to copy a content ofmemory from a virtual memory space of the source process to a virtualmemory space of the destination process; identify the source anddestination processes according to the attempt; and in response toidentifying the source and destination processes, selectively block theattempt according to a selection criterion determined according to atleast one member of a group consisting of an identity of the sourceprocess and an identity of the destination process.